Referência: 1985 - TSE - Enhanced Maintenance and Explanation of Expert Systems Through Explicit Models of Their Development:
Os sistemas especialistas existentes em 1985 sofriam de 2 deficiências:
- pouca capacidade de se explicarem para os usuários, seja esclarecendo, seja justificando tanto porque o sistema se comportou de certo modo quanto porque chegou a determinada conclusão;
- manutenção complexa, o que atrapalhava a extensão, bem como a modificação, tanto das capacidades do sistema quanto da base de conhecimento do mesmo.
Essas duas deficiências não eram irrisórias, tendo em vista que tanto serem capazes de se explicar quanto de serem atualizados, melhorados, e corrigidos, eram duas tarefas frequentemente necessárias no curso de desenvolvimento e utilização de tais sistemas.
Segundo Neches, a culpa da existência dessas limitações devia-se à representação inadequada, no código, do conhecimento e do raciocínio empregados no desenvolvimento do sistema especialista. Assim, Neches acreditava que os sistemas de sua época se beneficiariam de 3 elementos:
- existir, na base de conhecimentos do sistema, distinções explícitas entre os diferentes domínios de conhecimento empregados;
- um histórico formal do processo de desenvolvimento;
- um rastreamento da execução.
Explicações para o usuário
Sem essas fontes adicionais, os sistemas especialistas ficavam restritos a explicações compostas: ou de texto enlatado, ou de alguma paráfrase do código do próprio sistema. Isso levava os usuários a não ter certeza do quê o sistema era capaz de fazer de verdade, e se ocuparem de levantar uma miríade de hipóteses sobre como ele funcionava e porque o sistema teria comandado que o usuário fizesse A ao invés de B.
Texto enlatado obviamente é péssimo, pois é uma tarefa: manual, separada, e adicional, à manutenção do código. A tendência natural de texto manualmente inserido é que rapidamente perca a correspondência com o que o código do sistema representa de fato.
Por outro lado, a paráfrase do código é limitada exatamente pela informação que está representada no código, e mais ainda pela que não está lá. Só é capaz de explicar em muito baixo nível e muito pontualmente o que está se passando. Não pode nem descrever princípios de alto nível que motivaram as ações tomadas, nem explicar porquê essas ações tomadas realizam na prática qualquer princípio de alto nível.
O raciocínio que nunca foi explicitamente representado nunca estará disponível para explicação.
Modificações pelos programadores
A modificação do código do sistema devia-se geralmente a 1 de 3 razões:
- ou o código se baseou em um princípio ou pressuposto inválido;
- ou o princípio ou pressuposto era válido, mas o código o representou mal;
- ou outros tipos de questões, como a facilidade de implementação, ou a eficiência, levavam um método alternativo a ser preferido.
Em todos esses casos, as tarefas principais dos encarregados da manutenção do sistema eram: diagnosticar a causa da insatisfação, e então localizar e modificar todo o código pertinente. Contudo, como nos sistemas especialistas da época, não havia uma representação explícita da conexão entre os princípios de alto nível e o código que os representava, tanto o diagnóstico, quanto as modificações em si, se complicavam.
Afinal:
- se a base de algum segmento de código é inválida, ou não foi codificada apropriadamente, como, de posse apenas do código do sistema, reconstruir qual base teria sido essa?
- também, como determinar efeitos colaterais que outros trechos do código do sistema possam vir a sofrer ao se alterar um trecho específico? Consideremos o caso concreto do sistema MYCIN (“micina”), criado na década de 1970 e dedicado a identificar as bactérias responsáveis por causar alguma infecção, bem como a indicar os antibióticos adequados para o tratamento. Se um princípio dele precisasse ser alterado, dúzias de regras teriam de ser localizadas e modificadas. Mas, sem indicadores de onde essas regras estão no código, é fácil imaginar que algumas seriam esquecidas e múltiplas iterações de modificação e teste seriam necessárias para alterar o princípio.
- por fim, considerando o mesmo sistema MYCIN, e se alguém quisesse adicionar a ele conhecimento sobre um novo tipo de infecção? Na total ausência de indicadores no código, ninguém seria capaz de ter certeza de que todas as regras pertinentes foram localizadas. Não havia qualquer assistência ao programador para que ele tivesse certeza de que todas as regras necessárias foram adicionadas, muito menos de que estavam corretamente declaradas em código.